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ABSTRACT 


This  paper  discusses  the  axiomatic  and  functional  models  of  the 
semantics  of  structured  programming.  The  models  are  presented  together 
with  their  respective  methodologies  for  proving  program  correctness  and 
for  deriving  correct  programs.  Examples  using  these  methodologies  are 
given.  Finally,  the  models  are  compared  and  contrasted. 
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1.  INTRODUCTION 

I’rugramming  methodology  has  centered  around  the  use  of  a particular  set 
of  program  constructs,  chosen  because  they  provide  the  programmer  with  the 
ability  to  maintain  control  of  the  program  development.  This  control 
involves  the  ability  to  break  the  program  into  small  easily  understood 
pieces  using  a few  simple  structures  which  permit  the  verification  of  each 
step  in  the  development  process  before  going  on  to  the  next  step.  bach  step 
involves  the  decomposition  of  the  current  set  of  pieces  Into  another  set  of 
simple  structures.  This  development  technique  Is  commonly  referred  to  as 
stepwise  refinement. 

The  guidelines  for  choosing  these  basic  structures  and  the  ability  to 
prove  the  correctness  of  the  partial  solution  of  a program  are  based  on 
formal  models  of  the  semantics  of  various  program  constructs.  Associated 
with  each  of  these  constructs  there  is  a rule  for  verifying  the  correctness 
of  the  expansion  from  Its  specification  or  Intended  function.  This  paper 
discusses  two  such  models,  the  axiomatic  model  [Floyd,  1967;  Hoare,  1969] 
and  the  functional  model  [Mills,  1972,  19751.  In  the  next  section,  the 
basic  models  will  be  given  along  with  the  methodology  used  for  proving  the 
correctness  of  a program  In  each  model.  Section  3 gives  the  algorithm  for 
deriving  a correct  program  and  contains  an  example  derivation  using  each 
model.  Section  4 compares  the  two  models:  their  similarities,  differences 


and  connections. 


2.  BASIC  MODELS  OF  PROGRAM  CONSTRUCTS  AND  CORRECTNESS 

In  this  section,  the  two  models  are  defined  and  the  semantic  rules 
given  for  each  of  the  following  progr^un  constructs  where  SI  and  S2  are 
again  constructs  from  this  set: 


1. 

Assignment: 

x:“  f 

2. 

Sequence: 

SI  ; S2 

3. 

Iteration: 

while  b do 

SI 

od 

4. 

Choice: 

if  b then 

SI 

else  S2  fl 

if  b then 

SI 

£1 

For  the  purpose  of  this  paper,  a program  consisting  of  only  these  constructs 
will  be  called  a structured  program.  These  particular  constructs  were  chosen 
because  they  are  representative,  they  are  the  most  commonly  used,  and  they 
are  sufficient  for  the  examples  given  in  this  paper. 

Based  on  the  semantic  definitions  of  the  individual  constructs,  we  show 
the  standard  correctness  criteria  for  each  construct  and  how  to  apply  the 
correctness  criteria  to  a structured  program.  These  program  constructs 
permit  breaking  the  program  into  a hierarchy  of  structured  subprograms  such 
that  the  correctness  of  each  subprogram  can  be  proved  independent  of  the  rest 
of  the  program.  In  order  to  construct  this  hierarchy,  we  define  a prime 
program  as  a structured  program  with  no  structured  subprograms  consisting  of 
more  than  one  statement.  The  following  algorithm  is  used  to  construct  this 
hierarchy: 

while  the  program  consists  of  more  than  a single  logical  statement  ^ 
"find  a prime  subprogram  in  the  current  program;" 

"reduce  the  prime  program  to  a single  logically  equivalent 
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statement  - this  reduction  is  essentially  a syntatic 
grouping,  i.e.,  a compound  statement  (note  that  the 
resulting  program  consists  of  fewer  statements)" 
od 

This  algorithm  produces  a hierarchy  of  prime  programs  In  which  each  iteration 
of  the  loop  produces  a higher  level  in  the  hierarchy. 

As  an  example,  consider  the  program  given  in  Figure  2,1.  The  hierarchy 
of  prime  programs  is  the  following,  where  statements  are  indicated  by  their 
1 ine  number : 


The  particular  model  of  axiomatic  correctness  that  we  use  here  is  due 
to  [Hoare,  1969]. 


The  intended  function  of  a program,  or  part  of  a program  can  be 
specified  by  making  general  assertions  about  the  values  which 
the  relevant  variables  will  take  after  execution  of  the  program. 
These  assertions  will  usually  not  ascribe  particular  values  to 
each  variable,  but  will  rather  specify  certain  general  properties 
of  the  values  and  the  relationships  holding  between  them. 

. . . In  many  cases,  the  validity  of  the  results  of  a program  (or 
part  of  a program)  will  depend  on  the  values  taken  by  the 
variables  before  that  program  is  initiated.  These  initial  pre- 
conditions of  successful  use  can  be  specified  by  the  same  type 
of  general  assertion  as  Is  used  to  describe  the  results  on 
termination. 
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The  notation 

IP}  S {Q} 

is  used  to  state  the  required  connection  between  the  input  assertion  P, 
output  assertion  0,  and  program  (or  part  of  a program)  S.  The  program  S 
is  partially  correct  with  respect  to  P,  Q Iff  for  every  substitution  of 
values  which  makes  P true,  then  after  the  execution  of  S,  Q must  be 
true.  To  prove  (total)  correctness , we  must  also  prove  that  if  P Is  true 
then  S terminates.  In  this  paper,  we  Ignore  the  problem  of  termination 
since  the  techniques  used  are  Identical  for  both  models. 

To  prove  that  S Is  correct  with  respect  to  P,  Q,  the  first  order 
predicate  logic  Is  used  together  with  axioms  for  each  program  construct. 

These  latter  axioms  and  rules  of  Inference  are  given  In  Figure  2.2.  A 
complete  explanation  of  these  axioms  and  rules  of  Inference  can  be  found  In 
(Hoare,  1969].  In  the  Iteration  axiom  A3,  the  assertion  P Is  usually 
called  the  loop  Invariant . 

To  prove  the  correctness  of  a particular  program,  assume  that  every 
program  statement,  as  well  as  the  program  Itself,  has  both  a pre  and  post 
assertion  and  the  hierarchy  of  prime  programs  has  been  produced.  Since  each 
prime  program  In  the  hierarchy  has  both  a pre  and  post  assertion,  the 
correctness  of  each  piece  Is  proved  using  the  rules  given  In  Figure  2.2 
based  on  the  form  of  the  prime  program.  This  demonstrates  the  partial 
correctness  of  the  program. 

In  practice,  however,  every  statement  in  a program  Is  rarely  tagged 
with  both  Its  pre  and  post-conditions.  The  minimum  effective  requirement  is 


r 


Assignment 

A1  iP(f))  X f {P(x)) 

where  P(f)  is  obtained  from  P(x)  by  substituting 
f for  all  occurrences  of  x. 

Composition 

A2  If  )p}  SI  iR}  and  IR)  S2  IQl, 

then  {P}  SI;  S2  (Q). 

I terat ion 

A3  If  (P  A B)  S (P), 

then  IP)  while  B ^ S IPA^B) 

Condition 

A4  If  {p  A B)  SI  IQ)  and  IP  A B)  S2  iQ), 

then  IP)  ^ B then  SI  else  S2  fl  IQ) 

\5  If  IP  A B)  SI  IQ)  and  P A ^ B » Q, 

then  IP)  ^ B then  SI  f^  IQ) 

Consequence 


A6 

If 

IP)  S 

IQ) 

and 

Q * R. 

then 

IP)  S 

IR). 

A7 

If 

IQ)  S 

IR) 

and 

P » Q, 

then 

IP)  S 

IR). 
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to  be  jjiveii  the  pre  and  post-conditions  for  the  entire  program  and  the  loop 
Invariant  for  each  loop.  In  this  case,  the  pre  and  post  conditions  are 
{ generated  by  a top-dovm  process. 

I To  produce  the  assertions,  first  produce  the  hierarchy  of  prime  programs. 

• In  this  case,  a slight  modification  (or  normalization)  of  the  process  is  intro- 

} duced;  given  a sequence  SI  ; ...  ; Sn-1  ; Sn  consider  it  as  a composition 

i 

(SI  ; ; Sn-l)  ; Sn.  Given  the  l.lerrrchy,  the  pre-condition  of  each 

statemen*"  is  generated  by  a top-down,  recursive  algorithm  from  the  post 
I condition  (note  that  the  output  assertion  of  the  entire  program  is  assumed 

^ to  be  given) ; 

1.  Assignment:  x:=  f.  If  the  post-condition  is  ^(x)  , 
then  the  pre-condition  is  P(f)  as  given  in  rule  Al  of 
Figure  2.2. 

2.  Sequence:  Si  ; S2.  It  the  post-condition  is  Q,  then 
the  process  is  involved  recursively  to  find  the  pre-condition 
of  S2,  namely,  R.  this  process  is  then  repeated  on  SI  given 
R as  its  post-condition. 

3.  Iteration:  while  B ^ S od.  Note  that  it  is  assumed 

that  the  loop  Invariant  P is  given.  If  Q is  the  post 
condition,  it  must  be  proved  (as  part  of  the  proof  process)  that 
P and  -7  B ■»  Q.  P is  the  pre-condition  of  the  loop.  {P  and  Bl 
is  the  given  pre-condition  of  S and  P the  post-condition  of  S. 

The  process  of  finding  pre-condlt  ions  is  continued  on  S. 

4.  Choice:  B then  SI  else  S2  If  Q is  the  post- 

condition of  the  then  the  process  is  repeated  on  SI  and  S2 

[I 

B 

! 

f 

[ 

^ 
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with  Q as  their  post-condlL  ions,  yielding  HI  and  H2  as  their 
respect Ive  pre-ooadit ions . The  pre-cond  1 1 ion  of  the  Is 

(B  » HI)  A (-y  B ♦ P2).  Note  that  this  condition  can  normally 
be  greatly  simplified.  For  example,  if  PI  is  of  the  form 
P A B and  H2  is  of  the  form  P A -y  B then  the  pre-condition  is  P. 

The  proof  can  then  be  carried  out  as  before  but  much  of  the  work  has  been 
eliminated.  Since  the  pre-conditions  are  generated  from  the  post-condition, 
the  associated  program  part  must  be  correct  with  respect  to  these  conditions. 
Only  when  a pre-condition  is  given  (e.g.,  in  a loop  body)  must  it  be  proved 
that  the  derived  pre-condition  is  implied  by  the  given  pre-condition. 

In  order  to  illustrate  this  method,  tlie  correctness  of  the  program  given 
in  Figure  2.3  is  proven.  This  program  computes  the  product  of  two  natural 
numbers  A,  B by  repeated  addition.  Note  that  in  order  to  be  more  precise 
the  output  assertion  should  state  that  neither  A nor  B is  modified  by  the 
program;  in  the  axiomatic  model  it  is  assumed  that  unless  otherwise  stated 
no  program  modifies  its  input  values  (this  restriction  is  important,  as  shall 
be  seen  later)  . 

To  demonstrate  that  the  program  is  partially  correct  (i.e.,  that  it 
does  compute  A * B) , a more  formal  argument  than  usual  is  given;  tl»is 
formality  is  dropped  in  later  sections.  The  proof  of  the  program  given  in 
Figure  2. A uses  line  numbers  to  refer  to  program  parts  of  more  than  one 
statement . 

2.2  Functional  Correctness 


The  model  for  functional  correctness  was  developed  by  [Mills,  1972, 
1975].  Here,  the  intended  function  of  a program  is  stated  as  a functional 
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AXIOMATIC  PROOF  OF  SIMPLE  MULTIPLICATION 


I. 
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abstraction  which  suaunarizes  the  possible  outcomes  of  the  program  part  under 
consideration  independent  of  the  internal  control  structure  and  data 
operations.  The  goal  is  to  produce  loop-free,  branch-free,  and  sequence-free 
descriptions  of  the  effects  of  programs  on  data.  The  question  of  correctness 
reduces  to  the  question  of  functional  equivalence  between  the  program  under 
consideration  and  the  control-free  functional  version  of  the  program  with 
respect  to  its  intentional  effect  on  data;  i.e.,  the  high  level  function 
abstracts  out  any  local  variables,  etc.  This  functional  abstraction  Is 
meant  to  represent  a function  in  the  strict  mathematical  sense,  i.e.,  given 
a vector  of  Inputs  I and  a vector  of  outputs  0 the  function  (program 
segment)  defines  a rule  for  finding  0 given  I,  namely,  0 = f(l). 

The  program  S is  partially  correct  with  respect  to  f iff  for  every 
substitution  of  values  X such  that  f is  defined  and  f (X)  = Y,  then 
if  program  S is  executed  with  initial  state  vector  X,  its  final  state 

vector  is  Y.  To  prove  (total)  correctness,  we  must  prove  that  if  X is  an  , 

i 

element  of  the  domain  of  f then  S terminates.  (In  this  paper,  we  ignore  ' 

the  problem  of  proving  termination  since  the  techniques  used  are  Identical 
for  both  models.) 

To  prove  that  S is  correct  with  respect  to  f,  function  composition 
and  equivalence  are  used  together  with  functional  definitions  for  each 
program  construct.  These  functional  definitions  and  equivalences  are  given 
in  Figure  2.5.  Note  that  the  rule  for  assignment  given  in  FI  is  a 
simple  function.  A function  is  a model  of  assignment  in  that  it  maps  input 
values  into  output  values;  however,  it  differs  from  an  assignment  in  that  the 
input  and  output  spaces  are  always  distinct.  It  is  convenient  to  write  the 
Intended  function  of  a program  segment  as  a generalized  assignment,  in  which 
the  subscript  "in"  is  attached  to  all  input  variables  in  order  to  emphasize 
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FIGURE  2.5 


FUNCTIONS  COMPUTED  BY  PROGRAM  CONSTRUCTS 


Ass Ignmen t 
FI  y - f(x) 


Compos It  ion 

F2  f(x)  = [ g ; h ] (x)  = l>(g{x)) 


Iteration 

F3 


f (x)  = [while  p ^ g od ) (x) 

f(g  (x)  ) If  p(x) 

< If  -f  p(x) 


Conditions 


F4 

f(x)  - 

III  P 

then 

g else  h 

= 

rg(x) 

If 

P(x) 

(.h(x) 

If 

-7  P(^^ 

F5 

f(x)  = 

[If  P 

then 

g fil(x) 

fgCx) 

P(x) 

1 

If 

-?  P(x) 

this  separation  of  value  spaces.  From  the  point  of  view  of  an  assignment 
statement,  it  is  as  though  there  is  a distinct  copy  of  the  input  values. 

As  in  the  case  of  the  axiomatic  model,  in  order  to  prove  correctness  of 
a particular  program,  assume  that  every  prime  program  in  the  hierarchy  has 
an  intended  function  associated  with  it.  Then  merely  show  the  equivalence  ot 
each  prime  program  to  its  Intended  function  using  the  rules  given  in 
Figure  2.5.  This  yields  the  proof  of  partial  correctness  of  the  program. 

in  practice,  however,  every  prime  program  is  rarely  tagged  with  Its 
Intended  function.  The  minimum  effective  requirement  is  to  be  given  llie 
Intended  function  for  the  entire  program  and  for  each  loop.  In  this  cas»-, 
the  proof  is  carried  out  by  showing  the  functional  equivalence  of  the 
given  Intended  functions  with  their  associated  subprograms  consisting  ot  tlie 
top  level  prime  program  and  its  subhierarchy  down  to  the  level  of  any  given 
intended  functions.  In  this  process  the  functions  computed  by  the  sub- 
hierarchy  may  be  effectively  created  using  a top-down  recursive  trace 
algorithm  through  the  levels  of  the  subhierarchy  as  follows: 

1.  Assignment:  the  value  of  the  left  hand  side  variable  is 
symbolically  replaced  by  the  function  computed  by  the  right  hand 
side; 

2.  Sequence:  trace  through  the  first  statement  followed  by  the 
second  statement; 

3.  Iteration:  use  the  given  intended  function  in  the  trace; 

A.  Choice;  split  the  trace  process  into  two  cases,  the  then 
part  and  the  else  part,  and  continue  the  trace  process  through 


each  part  separately. 


FIGURE  2.6 

FUNCTIONAL  CORRECTNESS  OF  SIMPLE  MULTIPLICATION 


[Z  Ain  * Bin  , where  Ala  , Bin  ^ 0] 

» 

[Z  :=  OJ 

t' 

1.  Z :=  0;  * 

[Z  :=  Zin  + Ain  * Bln,  where  Bln  ^0]  l 

2.  while  B > 0 do 

1 

3.  Z :=  Z + A;  t 

4.  B :=  B - 1 i 

i 


16 


FIGURE  2.7 

FUNCTIONAL  PROOF  OF  SIHPLE  MULTIPLICATION 

1 . To  prove 


Ain  * 

Bin_7 

“ /fz 

1-  0 , 

Z 1 = 

Zln  + Ain  * Bln_7 

- ZT 

i«  Zln 

+ Ain 

♦ 311/7 

• ZTz 

.-o_7 

I-  0 

+ Ain  * 

Bln  •= 

Ain  * 

Bln7 

The  proof  that  t= 

0J7  is  the  function  achieved 

by  statement  ! 

is  obvious. 

To  prove 

Zln  + Ain  * 1 

Bln~7  “ /"while 

B > 0 

^ Z 

1-  Z + 

A ; 

B 

B - 

1 0^ 

Case  li 

B > 0 

1 must  show 

zm 

Zin  + Ain  * Bin  / ■ 

■ Zln 

+ Ain  1 

B 1 

- Bin 

- 1 ; 

Z 1 

» Z + A 

* £7 

Using  a table,  we 

get 

Step 

Z 

A 

B 

Initially 

Zln 

Ain 

Bin 

3 

Zin 

+ Ain 

Ain 

Bln 

4 

Zln 

+ Ain 

Ain 

Bln  - 

1 

f 

Zin 

+ Ain 

+ Ain  * 

(Bln  - 

1) 

Ain 

Bln  - 

1 

Zln 

Ain  * Bln 

Case  2i  £ 

! ^ 0 

: must  show  / 

Z 1- 

Zln  / 

ZJ  - 

Zln  + 

Ain  * 

Bln 

- 

Zin  + 

Ain  * 

0 

since  B > 0 

. B ± 

L 0 

- Zl^ 
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In  order  to  Illustrate  this  method,  the  partial  correctness  of  llie 
program  given  In  Figure  2.6  is  demonstrated  in  Figure  2.7.  Note  that  this 
program  Is  nearly  identical  to  the  one  given  In  Figure  2.3. 

3.  FORMAL  PROGRAM  DERIVATION 

In  this  section,  an  algorltlim  for  carrying  out  a derivation  of  a 
correct  program  is  given  and  an  example  presented  for  each  model. 

3 . 1 Algor i tliins  for  Formal  De r 1 v a 1 1 on 

The  algorithms  used  for  carrying  out  a formal  derivation  are  sui  pr i s 1 ngl y 
similar  in  the  two  models.  In  each  case,  the  stepwise  refinement  methodology 
is  applied  generating  possibly  both  new  subproblems  to  be  solved  and  ienuuas 
to  be  proved.  The  primary  difference  between  the  two  methods  is  in  stating 
the  problem  requirements  of  the  problem  at  each  level  of  the  decomposi t ion 
process . 

The  algorltlim  for  carrying  out  an  axiomatic  derivation  can  be  stated  as 
follows  (note  sets  are  denoted  as  [[  ...  ]]  ) : 

/*  Given  the  specifications,  organize  them  into  a function  f 
to  be  computed.  Let  P be  the  relations  (assertions) 
necessary  to  restrict  the  input  domain  of  f.  Let  Q be 
the  assertion  wliich  "captures"  the  output  of  f.  */ 

P "assertion  of  input  specifications" 

Q :»  "assertion  which  'captures'  the  output  of  f" 
problems-to-be-solved  :«  [f  ( P } S {Ql,  for  unknown  S )] 

while  problems-to-be-solved  ^ empty  do 


"using  some  strategy,  choose  a specific  problem 


18 


TABLE  3 . 1 

AXIOMATIC  LEMMAS  AND  SUBPROBLEMS 
FOR  PROBLEM  {P}  S (Q) 


Construct  Cho sen 


1.  X :»  f 


Lemma  to 

be  Proved  Subproblems 

P -*  Q where 
Q is  obtained  from 
Q by  replacing  all 
occurrences  of  x 
by  f 


2. 


S 


2 


3.  IX  B then  else  S^  ^ 


Determine  R 
(P)  (R) 

(R)  {Q} 

IP  A B)  Sj  IQ} 

<P  A B)  S^  IQt 


iP  A Bl  Sj  (P) 


4 


while  B do  od 


P A ^ B ♦ Q 
loop  terminates 
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to  be  solved,  denoted  IPl  S (tjf"  ; 

"choose  an  appropriate  program  construct  lor  S"  ; 

"prove  any  associated  lemma  (cf.  table  4.1)"  ; 

"add  any  new  subproblems  generated  (ct.  table  4.1) 
to  probleras-to-be-sol ved" 

od 

Depending  on  the  program  structure  cliosen  for  S,  zero,  one.  or  two  new 
aubproblems  may  be  generated.  As  Indicated  by  the  above  algorithm,  the 
process  continues  until  all  subproblems  have  been  solved. 

The  above  discussion  would  appear  to  indicate  tliat  the  only  "invention" 
required  in  the  process  of  deriving  a program  is  in  the  choice  of  the 
appropriate  construct  for  S.  Unfortunately,  this  Is  not  the  case.  Use 
of  the  composition  rule  (l.e.,  replacing  S by  requires  the  Invent  ion 

of  the  intermediate  assertion  R.  Fur tliermore , It  Is  usually  the  case  tliat 
wlieti  S is  to  be  replaced  by  an  iteration,  the  input  assertion  P Is 
unsuitable,  either  because  it  is  not  a loop  invariant  or  because  it  is  not 
true  that  P A — j B -♦  Q or  both.  Thus,  P must  often  be  strengthened  by 
means  of  the  consequence  axiom,  A7,  or  Q changed  by  means  of  axiom  Ab. 

A more  complete  discussion  of  the  problem  of  Invention  of  loop  assertions  and 
the  derivation  of  loop  bodycode  is  given  in  [Dljkstra,  1976;  Glshen  and 
Noonan,  1978). 

The  algorithm  for  carrying  out  a functional  derivation  can  be  stated  as 
follows; 

/*  Given  the  specifications,  organize  them  into  a functional 

form  where  I represents  the  set  of  Inputs,  0 represents 
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TABLE  3.2 

FUNCTIONAL  LEMMAS  AND  SDBPROBLEMS 


Construct  Chosen 

Lemma 

New 

Suboroblems 

1. 

Assignment 

— 

— 

2. 

Sequence 

f = ZTs* 

hj 

gf  h 

3. 

Choice 

III 

If  P 

gi  h 

(if  p then  g 

If  -T  P 

else  h fi 

4. 

Iteration 

f ‘-fra, 

t7if  P 

g 

(tfhlle  B do  a od^ 

(^identity  if  ->  P 

I 


A 


k. 


A 


the  set  of  outputs  and  f represents  the  mapping  from  the 
inputs  to  the  outputs.  */ 

1,  (),  f :=  convert-to-function-format  (specifications) 

funct  lons-to-be-decomposed  ;=  [[f]] 

while  functlons-to-be-decomposed  ^ empty  do 

"choose  a function  from  the  set  and  decompose  it  into  one 
of  the  acceptable  program  constructs"  ; 

"prove  tlie  decomposition  is  correct  (cf.  Figure  4.2)"  ; 

"add  any  nonprimitive  functions  to  functions-to-be- 
decomposed" 
od 

Note  that  the  functional  model  always  generates  a lemma  to  be  proved  and  at 
least  one  new  subproblem  except  when  the  function  can  be  achieved  directly 
by  an  assignment  (l.e.,  is  already  primitive).  As  indicated  by  the  above 
algorithm,  the  process  continues  until  all  subproblems  have  been  solved, 
tliat  is,  all  functions  have  been  fully  elaborated.  Like  the  axiomatic  model 
"Invention"  is  required  in  order  to  choose  the  appropriate  decomposition 
for  f . 

3 . 2 An  Example:  The  Primes  Problem 

In  the  sections  which  follow,  these  algorithms  are  applied  to  the  same 
problem,  namely,  the  problem  of  finding  and  printing  all  primes  less  than  or 
equal  to  a particular  Integer,  n.  For  both  the  axiomatic  and  functional 
models,  the  development  of  the  appropriate  specifications  and  the  derivation 
of  a correct  algor Itlim  are  shown. 

Informally,  the  program  is  to  compute  the  set  called  primes  = Upl , 
p2 , ...  » pm))  where  each  pi  is  a prime  number  less  than  or  equal  to  n ( 2). 


More  specifically,  each  pl  Is  a positive  Integer  and  satisfies  the  condition 
that  there  does  not  exist  an  Integer  x , 1 < x < p,  such  that  pl/x  is  an 
Integer.  Also,  there  are  no  prime  numbers  less  than  or  equal  to  n that 
are  not  In  the  set  primes. 

In  developing  a solution,  the  following  observations  can  be  made.  First, 
2 Is  the  first  prime  number  and  the  only  even  prime.  All  other  primes  are 
odd  and  therefore  It  Is  necessary  to  test  only  odd  numbers  as  additional 
prime  number  candidates.  Second,  any  number  that  has  a factor  has  a prime 
factor;  therefore,  it  is  necessary  to  divide  the  current  cand Idate  only  by  the 
primes  already  calculated.  This  means,  however,  that  the  primes  must  be 
saved  as  they  are  calculated. 

In  the  specifications,  primes  will  be  treated  as  a set,  a convenient 
choice  for  high  Level  specification,  but  implemented  as  an  array.  The 
necessary  properties  that  the  implementation  is  valid  could  be  stated  and 
proved  but  Is  irrelevant  to  the  purposes  of  this  paper. 

3.3  Axiomatic  Derivation  of  Primes 

In  the  axiomatic  model  a program  to  be  derived  always  starts  out  in  the 

form 

{P}  S {Q} 

where  P gives  the  required  assumptions  on  the  Input  and  Q the  intended 
function  to  be  computed  by  S.  Thus,  the  primes  problem  can  be  stated 
(3.3.1)  {2_;_nl  S (primes  » [[p  | p ^ n,  p is  prime  ]]  }. 

In  order  to  develop  an  axiomatic  solution  to  this  problem,  definition  of 
the  set  of  primes  is  needed.  In  order  to  distinguish  program  variables  from 


tuuctlon  definitions,  the  latter  will  be  underlined.  Tims,  the  set  of 


F 


I 


2 1 


primes  may  be  defined: 

(1.1.2)  primes  (K)  - empty  if  K < 2 

= primes  (K-l)  U (IK  | isprlme  (K)U  otherwise 
(1.1.1)  isprlme  (K)  = (Vp)  (p  - primes  (K-l)  - K rem  p / 0) 

Using  these  definitions,  the  primes  problem  can  be  restated  as: 

(1.1.4)  {n  ^2}  S (primes  = primes  (n)(. 

The  program  can  be  refined  by  decomposing  it  into  a sequence  using  axiom 
A2  in  order  to  compute  the  even  and  odd  primes  separately.  Then  using  axiom 
A1  on  tl>e  first  of  the  two  statements,  we  arrive  at  the  following  program: 

(1.3.5)  (n  ^ 2) 

primes  (1)  :=  2;  size  :=  1; 

I primes  = primes  (2)1 
SI 

(primes  = primes  (n)  ) 

The  program  part  Si  computes  only  odd  primes;  furthermore,  SI  must 
contain  a loop.  Following  [Dijkstra,  19761  and  [Gishen  and  Noonan,  19/8], 
the  necessary  loop  Invariant  is  developed.  Note  that  for  a given  y ^ 3, 
if  y is  even  then  primes  (y)  = primes  (y-1).  Since  n may  be  either  even 
or  odd,  the  following  loop  invariant  is  used: 

(primes  * primes  (y-1),  odd  (y) , y ^ n+2 } . 

Thus,  the  loop  (SI)  can  be  further  refined  using  axioms  A2,  A1 , and  A3  to 
arrive  at: 

(3.3.6)  (primes  = primes  (2)1 

y :=  3; 


] 

j 

i 


i 


I 

i 

I 


i 


J 


A 


Ik 

Iprlmoa  - p r 1 nif  a (y-1),  odd  (y) , y ^ 2 1 

while  y ^ n ^ 

S2 

od 

Iprinu'rt  “ pr  Iniew  (n)  I 

Note  that  provliiK  the  oori  oi’liiesH  ol  thlH  elaboration  requires  the 
proot  ot  the  tol lowing  lemmas: 

1.  primes  - p rimes  (2)  ► (pt  Imet.  » primes  ( J-1),  odd  (3), 

3 ^ n + 2) 

The  proof  is  obvious  slnee  Ic  Is  known  that  n 2. 

2.  (primes  " primes  (y-1),  odd  (y),  y ^ n + 2,  y > n) 

> primes  • primes  (n). 

'IVo  cases  arise.  It  n Is  even,  then  y - n + 1 and 
primes  “ primes  ((n  t 1)  - 1)  - primes  (n) . It  n Is  odd, 

then  y » n + 2 and 

primes  ■ pr Imes  ( (n  + 2)  - 1) 

“ primes  (n)  since  n + 1 la  even  and 

hence,  not  prime. 

In  a similar  fashion,  the  code  shown  below  is  produced  proceeding 
backward  through  S2: 

(3.3.7)  I primes  - primes  (y-1),  odd  (y)  , y ;^nl 
Isprlme  :«  true  ; J 2 ; 

(primes  “ primes  (y-1),  odd  (y) , y «_  n I 
isprlme  - (VK)  (IMi'-.l  * y rem  primes  (K)  / 0) 
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wlilje  ) ^ Sl/K  and  l«))rinu*  ^ 

l.sprimf  :•  (y  rein  primes  (J))  f*  O')  ; 
t :*  ) 1 1 

i.d  ; 

Iprinies  - primes  (y-ll,  mid  (y),  y •-  n,  Isprlme  - 
£s^rlme  (y)  I 

IJ  ls|irime  ihen 

slae  sliii’  4 1 ; 

primes  (size)  y 

11  : 

Iprimes  “ ptJnu'tJ  (y+l)  ^ primes  (y),  odd  (y),  y 2.  ''I 
y : “ y 4 2 

Iprimes  “ Pillil)*-'?  (V"!),  odd  (y) , y + 2 1 
Tlie  tliial  program  with  Its  Intermediate  assertions  as  doenmentat  Ion  Is  sluiwn 
in  Figure  ).3. 

1.4  Fiine t Iona  1 IKm'I Vii^t  Ion  ot  Primes 

In  tlie  t'unctlonal  approach,  tlie  problem  must  be  specified  as  a function 
tiom  a set  of  Inputs  to  a set  ol  outputs.  As  before,  tills  cun  be  staled: 

(1.4.1)  l>rlmes  - (|  p | p • n,  p Is  i>rlinel] 

As  with  tlie  previous  solution,  the  oven  and  odd  primes  are  computed 
sep. irately  and  the  prime  number  candidates  are  divided  only  by  pi  Inie 
numbers.  Under  these  conditions,  the  liinctimial  specifications  may  be 
rewritten  as: 

(1.4.2)  primes  - ll2ll  U oddprlmes  ('3,  n) 
using  the  functions: 


A 


FIGURE  3.3 

AXIOMATIC  SOLUTION  OF  PRIMES  PROBLEM 


In  2 1 

primes  (1)  :»  2 ; size  :»  1 ; 

(primes  ” primes  (2)1 
y 3 ; 

(primes  » primes  (y-1),  odd  (y) , y n + 2 1 
while  y ^ n ^ 

isprime  true  ; J :>=  2 ; 

(primes  » primes  (y-1),  odd  (y),  y n , 

isprime  “ (VK)  (1  ^ K ^ J ► y rem  primes  (K)  i 0) I 
while  J ^ size  and  isprime  ^ 

isprime  (y  rem  primes  (j)  0)  ; 

J j + 1 

od  ; 

(primes  ■ primes  (y  - 1),  odd  (y),  y i n, 

Isprime  “ Isprime  (y)) 
if  isprime  tlien 

size  :»  size  + 1 ; 
primes  (size)  :»  y 

11  ; 

(primes  » primes  (y)  - primes  (y  + 1),  otW  (y),  y „ | 

y y + 2 

(primes  - primes  (y  - 1),  odd  (y) , y n + 2) 
od 


( primes 


primes  (n)  ) 
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I 


1 


0> 


oddprlnies  (H.u)  “ [(I  | Isprlme  (•)]!  U oddpr Imes  (£+2,u) 

If  t ^ u 

“ empty  1 f t > ii 

isprime  (x)  - (V  p)  (p  > oddprlmes  ( j,  p - 1)  *■ 

X rem  p / {)) 

The  functional  specification  (3.4.2)  can  be  decomposed  into  two  functions, 
the  first  of  which  initializes  the  basic  data  and  tlie  second  defines  tite 
iteration  that  does  the  bulk  of  the  calculation. 

(3.4.3)  [ primes  [[2]]  U oddprlmes  (3,  1 

primes  (1)  :=  2 ; size  1 ; 
y :=  3 ; 

[primes  :=  primes.  U oddprlmes  (y.  , n,  )J 

The  implicit  loop  in  computing  odd  primes  can  now  be  made  explicit: 

(3.4.4)  [primes  :=  prlmes^^^  U oddprlmes  (y^j^»  ) 

while  y ^ n ^ 

[primes  :=  primes.  U [jy.  | isprime  (y . ) ]] 
in  in  — in 


od 

As  with  all  expansions,  tlie  associated  lemmas  given  in  Table  3.2  must  be 
proven.  Since  this  refinement  is  not  obvious,  the  expansion  is  verified. 
Since  Che  refinement  is  a loop,  three  lemmas  must  be  proved. 

1.  Does  the  loop  terminate?  Yes,  since  y is  incremented  by  2 
for  eacli  iteration  and  is  hounded  above. 

2.  Whenever  the  loop  test  is  true  (y  ^ n) , is  the  loop  body 


composed  with  the  intended  function  of  the  loop  equivalent  to 
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the  intended  function  of  the  loop.  This  is  demonstrated  using 
a trace  table. 


step  primes  y 


initially 

prlmesin 

^in 

loop  body 

primeSj^^  U 

“^n  1 

1 Isprime  (y^  )]) 

yin-^2 

loop  function 

prlmes^^  U 

K^in  1 

Isprime  (y^  ) ]] 

U oddprimes  "*■  2, 

“ prlmes^^  U oddprimes 


Since  the  final  value  for  primes  is  the  same  as  the  intended  tunction 
of  (3.4.4),  this  case  Is  proved. 

3.  Whenever  y > n,  is  the  Intended  function  of  the  loop  an 
identity?  Yes,  since  y > n,  the  set  oddprimes  empty. 

Thus, 

primes  ■ prlmes^^  , 
and  this  case  is  proved. 

Although  the  correctness  of  each  successive  expansion  is  not  verified,  it 
should  be  clear  that  it  is  both  possible  and  often  helpful  to  do  so. 

The  solution  process  is  continued  by  expanding  the  loop  body  given  in 

(3.4.4) . 

(3.4.5)  (primes  prlmesj^  U I iaprime  t 

y y,„  * 2) 

[Isprlme  :■  Isprime  (y.  )) 

— In 

if  Isprime  then 


size  size  + 1 ; 
primes  (size)  y 


The  final  expansion  is  tlie  loop  necessary  to  calculate  Isprlrae. 

(J.4.6)  [Isprime  :«  Isprlme 

Isprlme  :=  true  ; J :«  2 ; 
while  J ^ size  and  Isprime  ^ 

isprlme  :«  (y  rein  primes  (J)  0)  ; 

j :=  J + 1 
od 

The  complete  program  with  its  intermediate  functions  as  docmnentat ion 


is  given  in  Figure  3.4. 


FIGURE  3. A 


FUNCTIONAL  SOLUTION  OF  PRIMES  PROBLEM 

[primes  :-[121]  U oddprimes  (3,  n)] 
primes  (1)  :=  2 ; size  ;=  I ; 

y :=  3; 

[primes  :«  primes  U oddprimes  (y,  , n ) I 

in  •'  In  in 

while  y n do 

[primes  :=  primes^^  ^ ! isprime  (y^^^)]] 

y y,„  + 2] 

[Isprime  :=  isprlme  (y^^^)  ] 

Isprlme  :=  true  ; j ;«  2 ; 
while  j size  and  isprlme  do 
Isprime  (y  rem  primes  (J) 

/ 0)  ; 

J :=  J + 1 

od  ; 

if  isprime  then 

size  :=  size  + 1 ; 
primes  (size)  :«  y 

U ; 

y ;=  y + 2 
od 
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4.  COMPARISON  BETWEEN  THE  TWO  MODELS 

In  what  tollowa,  some  of  the  similarities  and  differences  between  the 
two  models  and  their  associated  correctness  and  derivation  approaches  are 
discussed . 

4 . 1 Simi lar i t ies 

Formal  Models  of  Individual  Program  Constructs  - Both  approaches  are 
based  upon  formal,  tractable  mathematical  models  for  specific  sets  ot  program 
constructs  In  Isolation  (not  as  operational  models  of  tlie  interrelationships 
of  program  constructs  at  runtime).  The  models  for  the  individual  constructs 
give  an  indication  of  the  complexity  of  tlie  semantics  of  the  constructs  ai\d 
thus  yield  a good  motivation  for  the  choice  of  a set  of  programming  language 
constructs  for  use  In  writing  provably  correct  programs.  They  both  deal  witli 
partial  correctness  only;  proof  of  termination  Is  a separate  issue  and 
identical  techniques  can  be  useii  in  both  models. 

Stepwise  Derivation  and  Correctness  - Rules  for  derivation  and 
correctness  are  based  on  the  application  of  the  particular  constructs  as  tliey 
are  decomposed  in  the  development  process  and  composed  in  tl>e  abstraction 
process.  The  techniques  are  applicable,  in  a stepwise  manner,  at  various 
levels  In  the  correctness  and  development  process,  dealing  with  only  small 
segments  of  code,  expanding  subspec 1 t Icat ions  in  a step  by  step  manner.  In 
this  way,  they  also  make  excellent  documentation  techniques,  each  subspecifi- 
cation being  useful  as  a high  level  comment  about  the  code  expanded  below 
It, 

Invention  - As  methodologies  for  proving  correctness,  both  appro.u'hos 


i 


t 


require  some  invention  in  the  creation  of  the  loop  Invariant  and  the  Intended 
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loop  function.  If  tlieso  are  not  given,  there  is  no  practical  way  of 
generating  them  which  Is  guaranteed  to  succeed  In  a reasonable  amount  of 
time.  A great  deal  of  work  has  been  done  on  heuristics  for  finding  loop 
Invariants  (Wegbrelt,  1974|.  Some  results  have  recently  been  published  In 
generating  Intended  loop  functions  [Bllkle,  1977]. 

A . 2 Differences 

Underlying  Mathematics  - The  underlying  mathematics  of  each  of  the 
models  is  different.  The  axiomatic  approach  uses  the  predicate  calculus 
while  the  functional  approach  uses  the  concepts  of  function  composition 
and  equivalence.  Consider  the  rules  for  correctness  given  in  Section  2. 

One  set  of  rules  uses  logical  consequence  auvl  the  logical  operators  of 
the  predicate  calculus,  while  the  other  uses  function  composition 
^decomposition  for  derivation)  and  function  equivalence. 

Statement  of  the  Specification  - The  functional  approach  states  tlie 
specifications  and  subspecifications  as  functions  from  the  Input  value  space 
to  the  output  value  space.  It  Is  a mathematical  function  In  the  strict 
sense.  The  axiomatic  approach  organizes  Che  specifications  and  subspeclfl- 
caClons  Into  Boolean  functions  represented  by  assertions  on  program  variables 
wliere  Che  Input  assertion  Is  a set  of  status  relations  among  the  Input 
program  variables  and  the  output  assertion  yields  true  or  false  depending 
upon  whether  the  output  variables  satisfy  the  appropriate  intended  function. 
In  Illustration,  consider  the  following  simple  program: 

I 1 ; 

I I + 1 


The  format  for  the  axiomatic  and  functional  approaches  are  given  below: 


{ true  } [1=2] 

I 1 [1=1] 

{1=1}  1 :=  1 

I I + 1 “ ^in 

(1=2)  1 :»  I + 1 

In  the  axiomatic  approach,  each  assertion  shows  what  is  true  about  the 
state  of  the  variables  at  the  particular  point  In  the  program  where  the 
assertion  appears.  The  assertion  is  given  in  terms  of  a relationship  between 
the  variables  involved,  e.g.,  (1=1).  In  the  functional  approach,  the 
function  defines  the  effect  a particular  set  of  statements  has  with  respect 
to  its  set  of  input  and  output  values,  e.g.,  the  statement  I :=  1 + 1 is 
defined  by  the  function  [I  = 1^^  + 1]  (shorthand  for  f = [[  1)«  I)  1 

I = + 1]]  ) and  this  is  true  independent  of  where  that  statement  is 

imbedded  in  the  program.  It  defines  the  effect  of  that  statement  in  a 
variable-free  way,  i.e.,  I represents  the  output  value  space  of  the  function 
and  I^^  and  1 represent  the  input  value  space. 


The  variable  free  aspect  of  the  functional  model  versus  the  variable 
dependent  aspect  of  the  axiomatic  model  is  demonstrated  by  their  model  of  the 
assignment  statement.  Consider  the  axiomatic  rule  for  assignment  given  In 
Figure  2.2.  In  the  assignment  x :=  f,  if  f is  any  expression  not  involving 
the  program  variable  x then  there  can  be  no  way  for  the  post  assertion  Q 
to  capture  the  old  value  of  x.  Thus,  in  the  multiplication  example,  in 
order  to  assert  that  Z = A * B,  neither  of  the  values  of  the  input  variables 
A or  B can  be  destroyed.  Since  the  algorithm  used  destroys  the  value  of  B, 
a copy  of  this  value  (Y)  must  be  made  in  order  to  prove  correctness.  This  is 
so  the  relationship  can  be  written  in  an  Invariant  way,  even  though  the  value 
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of  Y la  changing  dynamically.  The  output  assertion  requires  the  variable  B 
be  unchanged  as  a reference  point. 

■ In  contrast,  the  functional  model  handles  assignment  "naturally"  since 

a function,  like  an  assignment.  Is  a mapping  of  input  values  to  output 

I 

r 

values.  The  functional  specification  la  not  In  terms  of  the  variables  at 
all  but  the  values  of  the  variables;  l.e.,  Z and  Zln  represent  different 
value  sets  of  the  same  program  variable,  at  point  of  Input  to  the  program 
segment  specified  and  at  point  of  exit.  The  function  gives  the  relationship 
between  the  two  value  sets. 

Scope  of  Specification  - A functional  specification  defines  the  state 

of  affairs  of  only  the  program  part  for  which  it  is  the  intended  function. 

For  example,  the  function  [ I « I.  + 1 ] describes  only  the  behavior  of  the 

in 

statement  I I + 1.  However,  in  the  axiomatic  model,  the  assertion 
11  = 2)  depends  not  only  on  the  statement  I :=  I + 1 but  also  on  tlie 
previous  history  of  1. 

Any  change  in  a program  not  affecting  a particular  program  segment 
implies  that  the  functional  specification  for  the  segment  need  not  be  changed 
and  no  new  proof  of  functional  correctness  is  required  for  that  segment.  In 
addition,  a different  implementation  of  a functional  specification  can  be 
substituted  without  changing  any  proofs  of  correctness  in  the  remainder  of 
the  program. 

This  cannot  be  done  in  the  axiomatic  model.  An  assertion  about  a 
variable  depends  on  the  history  of  the  use  of  that  variable  and  on  its  inter- 
dependence on  other  variables.  In  addition,  assertions  contain  global 
information  about  nonlocally  affected  variables.  Thus  changes  in  a program 
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affecting  a particular  variable  are  not  necessarily  independent  of  the 
remainder  of  the  program  and  will  usually  require  new  proofs  of  all 
assertions  containing  that  variable. 

Bottom  Up  Correctness  - An  added  effect  of  this  difference  is  that 
given  a prograai  without  any  functional  specifications,  the  Intended  function 
for  any  prime  program  can  be  defined  depending  only  on  the  subhierarchy  of 
the  prime  program,  i.e.,  functional  correctness  can  be  approached  bottom  up. 
Suppose  the  functional  correctness  of  the  program  in  Figure  4.1  is  to  be 
proved  bottom  up.  The  functional  equivalent  of  the  loop  body  is 

1 I + I 1 

and  the  proof  is  trivial.  The  functional  equivalent  of  the  loop  in 
[ I :=  max  (I^^,  ) 

or 


if 

1 

< N 

In 

in 

in  i 

In 

if 

I, 

i “in  >• 

in 

The  proof  that  the  loop  is  equivalent  to  the  above  function  requires  proving 
that  the  loop  body  is  equivalent  to  its  function. 

Now  consider  the  case  for  the  axiomatic  method;  given 

{P}  I :=  1 + 1 IQ) 

P and  Q must  be  found.  Given  Q,  P can  b-^  found  from  Q via  the  assignment 
axiom  (Al).  Unfortunately,  there  is  no  way  to  determine  Q;  in  a sense 


Q must  contain  a great  deal  of  historical  information  about  the  use  of  the 
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variable  I as  well  as  Ils  relationship  to  the  nonlocally  referenced  N. 
Suppose,  however,  the  straightforward  approach  adopted  for  the  functional 
method  was  tried: 

(true*  I :=  1 + 1 fl  = !_,  +1}. 

in 

However,  given  tlie  invariant  for  the  loop  il  < N},  a proof  of  correctness 
requires  showing 

(P  A Bf  I :=  1 + 1 (P) 

or 

il  < N,  1 ^ N}  I :=  I + 1 11  1 N). 

Thus,  without  considering  the  loop  as  a whole,  there  is  no  practical  way  of 
determining  the  correct  loop  body  post-condition,  that  is,  there  is  no 
practical  way  to  assure  that  the  choice  of  the  post-condition  is  sufficiently 
strong  to  be  of  value  in  the  proof  of  correctness  of  the  loop  body. 

In  the  functional  approach,  any  such  bottom-up  process  is  guaranteed 
to  be  relevant  to  the  larger  construct.  In  fact,  in  the  program  in  Figure 
4.1,  given  the  program  as  a whole,  the  Intended  function  of  the  loop  is 
actually 


i 

s 


[ I = N 


in 


if  1 < 

in  — 


in 


Note  tliat  this  is  weaker  than  the  one  found  in  the  bottom-up  process.  This 
is  necessarily  so,  since  the  top-down  process  can  consider  only  the  relevant 
input  domain  (N  ^0)  instead  of  the  entire  input  domain  (N  an  integer). 


However,  it  should  be  noted  that  even  in  the  functional  model,  top-down 
proofs  are  easier.  Because  the  intended  function  is  more  specific  than  the 


t iiiu' t iolwi  I rqiilvali'ut  of  llio  program,  the  algohrafr  manlpvilut  fona  are  greatly 
almplifted  in  proving  the  neceaaary  functional  equivalences.  Kor  example, 
con.siiier  the  prohlem  of  fimllng  the  Intendeil  function  of  a binary  aearcli 
program  il  von  ilo  not  know  tlu>  input  array  la  ordered. 


'4.  i inter  re  I at  ionahip 


I'lieii*  is  an  inteieatlng  connection  ht^tween  l iie  two  mmlcla.  Tlie  intended 
tnnciion  t>t  a loop  may  he  e.aaily  converted  to  a loi>p  Invarljuit;  namely, 

I (x)  ” I (xin)  la  the  loop  invariant  |Milla,  19/5).  in  the  multiplication 
exampl**,  (In’  tunctional  spec  I f Icjit  Ion  tor  the  loo|>  Is  /.  :■  /In  Ain  * lltn 
t Inia  the  loiip  invariant  la 


I (x)  - f (xln) 

/ t A * H - Zln  4 Ain  * Hln 

/ - /In  f Ain  * Hln  - A * 11 

/ - /ill  i A * (Hln  - B)  , aince  A - Ain 

Z • A * (Bln  - B),  alnci’  /in  “ 0 from  the  initial  .laser  t Ion 

and  the  compos  it  ion  ol  I lu- 
atatementa  preceding  the 


In  the  piogram  In  Kigure  2.1,  the  v.’irlahle  B plays  the  role  of  Bln  ami  the 
variable  Y plays  the  role  of  B. 


5.  CONCI.IISIDN 


It  should  he  clear  from  the  previous  disciiaaion  that  both  models  yield 
a methodiilogy  of  program  derivation  and  ciiri  ect  ness.  I'he  appioathea  have  a 
great  deal  in  common  hut  they  are  different;  tin*  axlom.it  ic  approai’h  emph.ial/.ei 
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the  relations  between  the  variables  and  the  functional  approacli  emphasizes 
the  Independent  variable-free  functions  performed  by  the  various  program 
subpieces. 

It  is  not  clear  which  approach  is  more  effective  in  an  operational 
environment.  It  may,  in  fact  depend  upon  the  particular  environment,  and 
the  problems  that  arise.  Enough  is  still  not  known  about  the  kinds  of  errors 
designers  and  programmers  make  in  different  environments  and  therefore  whether  ’ 

a variable-free  or  variable-dependent  approach  is  best.  One  possibility  is 
for  the  developer  to  be  aware  of  both  and  use  both  in  the  development  of 

j 

programs.  Certainly,  one  could  be  used  in  formally  deriving  the  program  and  : 

tlie  other  as  a commenting  aid;  t^.g.,  use  tlte  functional  approach  in  tl\e 

i! 

development  to  aid  in  the  partitioning  and  modularization  of  the  independent 

l! 

program  parts  and  use  assertions  as  comments  to  aid  the  programmer  in  under-  I' 

standing  the  relationships  between 
appear  to  complement  each  other  in 


I 

i 


the  variables.  In  either  case  the  models 
the  insiglit  they  provide  to  tlie  developer. 


I 
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